home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Turnbull China Bikeride
/
Turnbull China Bikeride - Disc 2.iso
/
STUTTGART
/
NEWSOFT
/
AUGUST
/
BREADPAT
/
!BreadPtch
/
!Help
next >
Wrap
Text File
|
1997-08-04
|
13KB
|
255 lines
BREADPATCH (version 1.3)
========================
PLEASE READ THIS HELP-FILE CAREFULLY BEFORE ATTEMPTING THE PATCH!
Slight changes since the first version:
- vectored system calls are now trapped correctly. This allows the native SID player
(RealSIDPlayer, see ftp://utopia.hacktic.nl/pub/c64) to work, for instance.
- corrected CIA keyboard / joystick reading: $DC00 = $7F, not $FF when nothing's
pressed. That makes some programs work that used to have problems reading the
joystick in port 2 (e.g. Commando).
- I got hold of release #2 and did the patch myself, so now I can be really sure
it works OK. I did find a wrong branch in the patched patch used in version 1.2.
This is a patch for the C64-Emulator "!Breadbox" V0.44 (Rel #1/2). It gives you simple
IO, simulating Floppy Disc Drives (Device# >= 8) and Printers (Device# = 4). This
is done by trapping certain OS calls, like those for loading/saving files and
anything to do with open channels on the IEC bus. Anything that goes beyond
this (like Floppyspeeders that download a program into the Floppy Disc Drive)
will not work with that Patch either but a large number of stuff will.
In addition it cures the bug in displaying hires mono mode. For some reason Denys
brought the background colour into it which could result in a bad address offset
which in turn totaled the machine. Hires mono is completely independent of the
background colour register - this is now fixed, everything works fine and I
haven't had a single crash since :-)
This is NOT an official patch - I am in no way related with Daydream Software or
Denys Bogatz. Thus if anything goes wrong don't blame them. Don't blame me either
because as usual with free stuff the author refuses any kind of responsibility
blahblahblah (see below).
Patching your copy of !Breadbox:
--------------------------------
First up: the !BreadPtch application folder contains two versions of the patch
binary: !RunImage (for release#1) and !RunImage2 (for release#2). By default !RunImage
is used (i.e. release#1). If you have release#2 you must either change the !Run-File
to start !RunImage2 or rename !RunImage2 into !RunImage. That done you're ready to
start patching the Breadbox.
Open the !Breadbox application-folder: this contains the file CODE. Start !BreadPtch
by double-clicking on its filer icon. This will open a small window with a greyed-out
sprite icon and two writable icons. Dragging the CODE file (_not_ the application itself)
onto the patch-window will result in said icon being un-greyed. The filename you want to
save the new CODE file under has to be entered in the writable icon under the sprite
icon. This is set to CODE+ by default to avoid casual overwriting of your original file.
In the writable icon headed "EmuMode" you can specify what screen mode the emulator
should use when active. The default one used by !Breadbox rel#1 is mode106 - although the
mode module is called mode126. However mode 106 plays merry hell with the Colour Card
Gold, so I changed it to mode 126 on my system. You have to enter the correct mode
number here, there's no default value used by the patcher. Remember to change the
module defining the screen mode too if you make !Breadbox use a different mode (using
!CustomVDU, for instance)! Rel#2 uses mode126 by default, for all I know.
If all is set up alright drag the sprite icon into the destination directory window
as with any SaveAs box (only filer windows are allowed!). DO NOT OVERWRITE YOUR ORIGINAL
CODE-FILE!!! This is very important. Don't write onto the original floppy disc either
since that might lead to trouble with Daydream Software should you want an upgrade.
Make a copy of !Breadbox on your harddisc instead - most people will have put it
there first thing anyway - and write the new CODE file in there. If you save the patched
file under a different name than "CODE" (which I recommend) make sure the !Run-file
starts the correct one. Patching might take some time unless a hard- or RAM-disc is
involved (a RAM disc is a "bit" over the top, though). You should have about 600kB of
free RAM available for patching!
After successful patching !BreadPtch will automatically terminate itself and you'll
have the new CODE file ready for use (it's a bit over 540k). Since it's longer than
the original file you'll have to alter the !Run-file to give the program a 544k wimpslot
(the original had 540k). The size of the patched file is due to uncrunching. You may cut
down its size again using e.g. !Crunch (which seems to have been used on the original as
well).
If your version of !Breadbox is incompatible with the one this patch was written for
the patching will be aborted. !BreadPtch checks quite a lot of things on the way so
if it runs without complaining there shouldn't be any complications later on.
You should now have a working version of the patched Breadbox.
I know the patch program could be better but then why bother for a one-way application?
IO from/to where?
-----------------
The virtual Floppy disc drive reads from VC1541$Path so you have to set up that variable
to point to the directories or VC1541 disc images that hold the files you wish to
access. You may specify more than one directory - in that case all of the files contained
in these can be accessed; the directory will be read from the first, new files (ones that
aren't found in any of the directories on VC1541$Path) are created in the last directory
(this is RISC OS specific, don't blame me). Please note that _all_ file accesses will affect
files in all the specified directories, which includes deleting files (files with matching
names are deleted from all of these directories!). You can check if you've set up the
path correctly by typing "*cat VC1541:" on the CLI which should catalogue the first
directory on the path.
If you're loading/saving files there will be no messages along the lines of "searching
for <filename>... loading", only a "ready." after it's finished. Unless you get an error
the load will have been performed OK.
Error messages may be completely wrong. I didn't bother to set the correct error for
everything that can go wrong; hardly any program cares anyway. E.g. if a file can't
be found you get a "break error". So don't take these errors literally, the messages
might not have anything to do with the real cause.
Accessing files within a VC1541 disc image (extension .D64) is not supported directly by
this program, all file accesses are handled through RISC OS. Hence you'll have to run
D64ImageFS for that (which I uploaded on the same FTP servers as this patch). Even without
D64ImageFS you can read an image's directory and access it with block-read/write commands.
A speciality of the load/save routines is that they only access the emulated C64's RAM,
not the ROM. I.e. saving &a000-&c000 will save the RAM under the BASIC ROM, no matter
what the contents of $01. Since saving the ROM doesn't make much sense this is usually
no problem. A special case is the IO-area from $D000-$DFFF (both for load and save). If
the start-address is less than $D000 the operation will be applied on the RAM, even
if the end-address is beyond $D000. I don't know any program which would do that,
actually, since loading to $D000 will completely screw up your machine, but there are
some programs which go beyond $D000 and hence need a special loader on a real C64,
but because of this distinction not with the emulator. If the start-address lies between
$D000 and $DFFF, however, the operation will be applied on the IO-area. I can only
think of one occasion where this would be handy and that's loading/saving the colour-RAM
from $D800-$DBFF, that's why I did the distinction.
Another special thing about load/save: these are always called for Floppy Discs, no
matter what device you specify. Thus you can load a file with ``load "<file>"'' instead
of ``load "<file>",8''. You only have to bother with the usual device-numbers if you
need a secondary-address other than zero.
I might change this in future versions but for now I couldn't care less.
Directory routines differ for RO-directories and VC1541 disc images since the latter
contain some additional info (like the disc image's name and the number of free
blocks). RO directories will be given a generic header and footer, VC1541 disc
images will look more or less exactly like they used to on a real C64.
The only supported directory format is the one where the secondary address is 0! That
means a BASIC-file rather than the raw data. This is by far the most widespread format
used, I don't think this should pose any problems. The directory may be loaded into
memory (load "$",8) or opened as file and read in byte-for-byte. Opening another
directory-file while the previous one isn't closed will reset the previous one - this
patch only supports 1 open directory file at a time. This also should not be a
limitation - but I don't know what the original VC1541 did in that case which
essentially doesn't make any sense.
Data sent to the printer (Device# = 4) is spooled into the file "VC1541:_C64_Prnt_".
If you opened the printer channel via open 1,4,x,"<stuff>" the <stuff> will be lost -
sorry but once again this hardly ever matters at all since practically all programs
open the channel without any <stuff> and if they do all that's lost are usually some
escape-sequences to the printer.
DON'T MAKE SNAPSHOTS WHILE FILE OPERATIONS ARE IN PROGRESS. The snapshot will save
the C64-RAM but not the file state of the emulator and thus it'll be useless later on.
But that's no different from a real C64 where you can't just make a snapshot in the
middle of an IO-operation either. Making snapshots shouldn't crash anything, though.
Supported Floppy-Commands:
--------------------------
You can send Floppy-commands to a channel with secondary address 15 as on a real C64:
open1,8,15,"s:file1,file2": close1
will delete file1 and file2 just like in the good ole days. In the same way you can
read the Floppy's status by reading from such a channel. Currently there are only two
different states of the virtual Floppy, OK and error - live with it.
1) File-commands:
~~~~~~~~~~~~~~~~~
copy:new=old1,old2,... (c:...)
initialise (i) -- Doesn't do anything.
new: (n:) -- Doesn't do anything. Use D64ImageFS instead.
rename:new=old (r:...)
scratch:file1,file2,... (s:...)
validate (v) -- Doesn't do anything. Use D64ImageFS instead.
2) Direct access-commands:
~~~~~~~~~~~~~~~~~~~~~~~~~~
These commands access a disc image directly. These will always access the _first_ object
on VC1541$Path so if you want to use these commands make sure this object is a disc
image! If it isn't... well, there shouldn't be any data loss or real hazards but avoid
it anyway.
In the following "c" stands for the channel (secondary address), t/s for track/sector,
n for the Floppy number (usually 0 - this is _not_ the Floppy _device_ number (8)) and
p for a pointer position (0<=p<=255)
block-allocate:n,t,s (b-a:...) Allocate a block
block-free:n,t,s (b-f:...) Free a block
block-read:c,n,t,s (b-r:...) Read a block into the buffer for channel c
block-write:c,n,t,s (b-w:...) Write a block from the buffer for channel c
buffer-pointer:c,p (b-p:...) Set the buffer pointer for channel c to p
user1:... (u1:...) Same as b-r
usera:... (ua:...) Same as user1
user2:... (u2:...) Same as b-w
userb:... (ub:...) Same as user2
b-r/w and the user-commands are not 100% identical on a real C64. This is another small
incompatibility. But then I never had any _decent_ documentation on the Floppy's innards
and it seems to work anyway.
Like on a real C64 you can open a channel to a Floppy buffer by opening a file with the
name "#". Unlike on a real C64 a buffer number (e.g. "#7") will be ignored, instead the
next free buffer will be allocated. The number of buffers is currently limited to 4
which should be more than enough within the limitations of the emulator.
Important note: DO NOT CHANGE VC1541$Path WHILE A "#"-FILE IS OPEN! The reason is that
upon opening such a channel the emulator checks whether the first object on VC1541: is
a disc image and opens it if so. If you change the path you'll still read from the
image you opened and I don't know what kind of stuff might turn up apart from that.
Remember that changing the path is like changing a disc on a real C64 and don't do
anything with the path where you wouldn't do anything with a disc!
LEGAL:
======
This unofficial patch is Freeware. You may copy and use it freely as long as no part
of it is changed and it isn't sold for profit. The author will not be held responsible
for any kind of damage resulting from using this patch. Use it entirely at your own risk!
(It runs dead stable for me, BTW).
CONTACT:
========
Andreas Dehmel
Am Schorn 18
82327 Tutzing
Germany
dehmel@informatik.tu-muenchen.de
"Exalt!
The queen of death-white winter enthroned
Evil-resplendent, in dusk red seething skies
Foam-flecked nightmares drag a moon
of Draconian design."
(Cradle of Filth - Queen of Winter, throned)